How To Obtain The Taiwan Cloud Server Address And Complete A Quick Connectivity Test

There are usually two ways to obtain the server address on the cloud platform: viewing it through the console and querying it through API/command line. If you need to quickly locate the address in Taiwan, first confirm the region label where the instance is located (such as "ap-northeast-1-tw", "asia-east1" or the Taiwan availability zone customized by the supplier).

Log in to the cloud service provider console, enter the instance list page, select the corresponding instance, check the "Network/Public IP/Private IP" field to obtain the public IP or private IP of the instance; if it is a load balancing or elastic IP, you need to check the bound IP on the corresponding resource page.

Using the CLI command or API request provided by the cloud vendor, you can obtain it in batches. Example: Use aws cli (if it is GCP or Azure, please replace it with the corresponding command):

Linux/Windows: (command example) aws ec2 describe-instances --filters "Name=availability-zone,Values=ap-northeast-1-tw" --query "Reservations[*].Instances[*].PublicIpAddress"

Pay attention to distinguishing between Public IP (reachable externally) and Private IP (reachable only within the same VPC or VPN); if it is released to the outside world through NAT or load balancing, you need to query its external network egress address or DNS.

Only obtaining the IP is not enough to confirm reachability. It should be verified through basic network testing (Ping, Traceroute) and application layer port detection (such as TCP port, HTTP/HTTPS).

Run under Windows: ping Public IP; the same applies to Linux/macOS. If Ping fails, it does not necessarily mean that it is unavailable, because the target may block ICMP.

Use traceroute (Linux/macOS) or tracert (Windows) to determine the path and hop delay to the Taiwan node: traceroute -n Target IP. If there is packet loss or timeout at one of the intermediate hops, it may be an ISP policy or cross-border link issue.

If Ping is blocked, please try TCP port detection (such as SSH/TCP 22, HTTP/TCP 80/443), or use curl/wget to access the domain name to test application layer connectivity.

Port connectivity determines whether the service is available. Common tools include telnet, nc (netcat), curl, openssl. Different tools are suitable for different protocol layers.

Test SSH (port 22): telnet IP 22 or nc -vz IP 22. If the connection is successful, the TCP three-way handshake is normal.

Use curl to check the application response: curl -I http://IP or domain name or curl -vk https://Domain name. Observe HTTP status codes and SSL handshake information.

If the port is restricted by the firewall, you can try to initiate a test from the cloud intranet or other instances in the same region to confirm whether it is a problem with the target host's firewall rules or a cross-segment link problem. In addition, security group rules can be temporarily opened for troubleshooting, but pay attention to security and the principle of least privilege.

Traceroute and MTR can reveal delays or packet loss points in links and are useful tools for cross-border or cross-regional diagnosis. MTR makes it easier to detect jitter and packet loss in continuous measurements.

Run mtr -rwz Target IP or traceroute -n Target IP on Linux, and tracert -d Target IP on Windows. The -n or -d parameter prevents reverse DNS from affecting display speed.

View average latency, maximum/minimum values, and packet loss rate for each hop. If the packet loss rate suddenly increases on a certain hop but then recovers, it usually means that the device on that hop has ICMP restrictions. If subsequent high packet loss or high latency occurs on multiple hops, it means that the link is actually affected.

Common network paths when connecting to Taiwan will pass through nodes in mainland China, Hong Kong or Japan; if high latency occurs at the exit node, contact the operator or cloud service provider to troubleshoot the cross-border transit link or submarine cable problem.

When connectivity problems are encountered, the root cause can be quickly located through step-by-step troubleshooting, from the local to the target, from the link to the host, to the application and security policy.

1) Local check: Confirm that the local network is normal (such as being able to access other public network services).

2) DNS resolution: If you use a domain name, first use nslookup or dig to confirm whether the resolved IP is consistent with the cloud.

3) ICMP/TCP test: ping, traceroute, telnet/nc, curl are tested in order, and failure points are recorded.

4) Cloud security settings: Log in to the cloud console and confirm whether the security group, network ACL, and host firewall (iptables, ufw, Windows firewall) allow the corresponding port and source IP.

5) Routing and NAT: Check whether there are NAT/elastic IP binding errors or SNAT export inconsistencies that cause the external address to be different from expected.

Collect traceroute/mtr output, ping logs, security group rule screenshots, and cloud console binding information, and submit them to the cloud service provider or operator. Providing detailed test time, source IP and target IP can speed up positioning.

ping Destination IP

traceroute -n Target IP (or tracert -d Target IP)

mtr -rwz Target IP

nc -vz Destination IP 22

curl -I http://Domain name or IP or curl -vk https://Domain name